來到第三天啦
相信各位一開始接觸，第一次看到 Kubernetes 架構圖，
很多人的反應都是：

API Server
etcd
Scheduler
Controller Manager
kubelet
kube-proxy
Container Runtime

蛤 這麼多東西 各自代表啥？想開始準備一個一個查
查完後沒有很懂很連貫，然後決定先跳過。

其實不需要。

我們今天只回答一個問題：

當我說「我要建立三個 nginx Pod」之後，到底發生什麼事情？

Kubernetes Cluster 先分成兩種 Node

最簡化可以畫成：

Kubernetes Cluster
│
├── Control Plane
│
└── Worker Node

Control Plane 可以理解成：

大腦。

Worker Node 則像：

真正工作的機器。

Application Pod 通常跑在 Worker 上。

API Server：Kubernetes 的正門

假設輸入：

kubectl get pods

kubectl 並不會直接跑去每台 Server 找 Pod。

它會：

kubectl
↓ 呼叫它！
kube-apiserver

API Server 是 Kubernetes Control Plane 的主要入口。

不只是 kubectl。

其他 Controller、Scheduler、外部工具也主要透過 Kubernetes API 溝通。

所以可以先記：

API Server
＝ Kubernetes 的正門。

etcd：Cluster 的記憶

Kubernetes 必須記得很多事情：

有哪些 Pod？
有哪些 Deployment？
ConfigMap 是什麼？
Secret 是什麼？
Node 狀態如何？
Desired State 是什麼？

這些 Cluster State 需要地方保存。

核心就是：

etcd

它是一個 distributed key-value store。

先不用研究 Raft(etcd 的分布式共識演算法)是如何運作。

目前只要知道：

API Server
↓ 呼叫
etcd

Kubernetes 的重要狀態會被保存起來。

因此 etcd 對 Cluster 非常關鍵。

Scheduler：這個 Pod 到底要去哪一台 Node？

假設現在有：

worker-1
worker-2
worker-3

我們建立一個 Pod。

這時 Pod 一開始沒有 Node。

Scheduler 就會考慮：

哪台 Node CPU 足夠？
哪台 Memory 足夠？
nodeSelector 符合嗎？
Affinity 呢？
Taint / Toleration 呢？

最後做出決定：

這個 Pod → worker-2

所以：

Scheduler
＝ 幫 Pod 選 Node。

注意它不是負責真的啟動 Container。

它主要負責：

Pod 決定去哪裡 (也就是分到哪個 Node)。

kubelet：Node 上真正執行工作的人

每一台 Node 上通常都有：

kubelet

Control Plane 告訴：

worker-2
你要跑這個 Pod

worker-2 上的 kubelet 就會確保 Pod 真正被建立。

所以：

Scheduler
＝ 決定去哪

kubelet
＝ 確保它真的跑起來

Container Runtime

kubelet 本身不負責真的執行 Container。

它需要 Container Runtime。

例如：

containerd

因此可以理解成：

kubelet
↓
CRI (Container Runtime Interface)
↓
containerd
↓
Container

後面我們會再談 CRI (Container Runtime Interface)。

Controller Manager：一直盯著 Desired State

還記得 Day 1 嗎？

Desired Pod = 3
Actual Pod = 2

誰一直在注意這些差異？

各種 Controller。

Controller Manager 裡運作著許多 Controller Loop。

概念就是：

Observe
↓
Compare
↓
Act
↓
Repeat

觀察目前狀態。

跟希望狀態比較。

不同就採取動作。

然後永遠繼續。

這就是 Kubernetes 很核心的：

Control Loop。

把完整流程串起來

假設我們之後建立：

replicas: 3

大概可以理解成：

1. kubectl
      │
      ▼
2. API Server
      │
      ▼
3. etcd 保存 Desired State
      │
      ▼
4. Controller 發現需要 Pod
      │
      ▼
5. Scheduler 幫 Pod 選 Node
      │
      ▼
6. Node 上 kubelet 發現 Pod
      │
      ▼
7. Container Runtime 執行 Container

這張流程圖非常重要。

之後遇到問題，就能開始問：

是 API Server？

Scheduling？

Node？

kubelet？

Container？

而不是把整個 Kubernetes 視為一個黑盒子。

Kubernetes 為什麼這麼「繞」？

因為它是：

Distributed System。

它不是：

一個程式收到 command
→ 執行完
→ 結束。

而是大量元件共同維持一份 Desired State。

這也是為什麼 Kubernetes 很多事情是：

Eventually

而不是你 command 一按下去，所有事情瞬間完成。

Day 3 小結

今天不用死背所有 Component。

先建立這個版本：

API Server
＝ 入口

etcd
＝ 記憶

Scheduler
＝ Pod 去哪

Controller
＝ Desired State 的守門員

kubelet
＝ Node 上執行 Pod

Container Runtime
＝ 真正跑 Container

明天開始！
我們就會真的在自己的電腦裡建立：

1 Control Plane
+
2 Workers

而且不需要三台 Server。